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Vorrichtung zum Aufbau eines Protokoll- Stacks 
und zugehoriges Verfahren 



BESCHREIBUNG: 

Die vorliegende Erfindung betrifft eine Vorrichtung zum Aufbau 
eines Protokoll -Stacks , ein zugehoriges Verfahren sowie einen 
Protokolltester mit einer derartigen Vorrichtung. 

Das Gebiet der ProtokollmeStechnik ist in einem besonderen MaSe 
innovativ. Nach jeder Weiter- und Neuentwicklung von Telekommu- 
nikations- und Netzwerkprotokollen stehen die Hersteller und 
Betreiber von Telekommunikations- und Netzwerkgeraten vor dem 
Problem der Funktions- und Conf ormancekontrolle der neuen An- 
lagen. Aufgrund des Wettbewerbs ist jeder Hersteller bemuht, 
sein Produkt so fruh wie moglich auf den Markt zu bringen. Durch 
das hohe Tempo dieser Entwicklung werden Hersteller von Proto- 
kolltestsystemen in einem besonderen MaSe gef ordert . 

Urn die Testzeiten fur ihre Anlagen so kurz wie moglich zu halten 
und das Testpersonal mit wenig Protokollwissen zu belasten, 
setzen Hersteller haufig Protokollemulationen auf den. Protokoll - 
testsystemen ein. In der Praxis werden Emulationen eines Proto- 
kolls haufig so erstellt, daS die Emulationen jeweils einzelne 
Protokollschichten nachbilden. Durch das Verbinden der einzelnen 
Protokollschichten zu einem emulierendeh System konnen auf diese 
Art ganze Protokoll -Stacks oder auch ausgewahlte Telle eines 
Protokoll -Stacks nachgebildet werden: Die einzelnen Protokoll- 
schichten werden abstrakt betrachtet und leiten so Daten von 
Schicht zu Schicht weiter. In den Spezif ikationen von Protokol- 
len werden hierbei in der Regel sogenannte Primitiyen verwendet, 
um die Kommunikation zwischen den Protokollschichten zu be- 
schreiben. Die Erstellung solcher Protokollemulationen stellt 
einen erheblichen Arbeitsaufwand dar. 



/ 

I 



In vielen Fallen bestehen neue Protokoll -Stacks vollstandig oder 
zumindest fast vollstandig aus bereits bekannten Protokoll - 
schichten, Aber auch in diesen Fallen mufi fur das Protokoll test - 
system eine neue Applikation zusammengestellt werden. An dieser 
Stelle wird eine groSe Flexibilitat an ein moglichst einfaches 
Vorgehen fur die Modifikation von Protokoll-Stacks gewunscht, 

Im Stand der Technik ist es bei Protokollsystemen, die die Fa- 
higkeit besitzen zu simulieren und dazu Protokollemulationen 
einsetzen, bisher ublich, statische Applikationen anzubieten, 
d*h. daS der Anwender fertige Applikationen aufrufen und nutzen 
kann. In diesem Zusammenhang wird verwiesen auf das ISO OSI 
Referenzmodell, das durch diese Bezugnahme in den Of f enbarungs- 
gehalt der vorliegenden Anmeldung auf genommen wird. In diesem 
Fall ist es dem Benutzer nicht moglich selbststandig deh Proto- 
koll-Stack durch Zufugen, Ersetzen oder Entfernen von Protokoll- 
schichten zu modif izieren . Das Herstellen einer neuen Applika- 
tion, d.h. das Zusammensetzen vorhandener Emulationen von Proto- 
kollschichten erfordert spezielles Systemwissen sowie Kenntnisse 
uber die verwendeten Komraunikationsmechanismen und kann meist 
nur vom Hersteller vorgenommen werden. Fur den Protokolltester 
entsteht daraus das Problem, daS er nur eine endliche Anzahl von 
Applikationen mit jeweils vorgegebener Konstellation von Proto- 
kollemulationen vorfindet. 

Andere Losungen- wie z.B. Stream-Konzepte haben sich bei Proto- 
kolltestsystemen nicht durchgesetzt . Stream-Konzepte konnen nur 
dann eingesetzt werden, wenn eine exakte Schichtxxng mit einer 
Protokollschicht auf einer anderen vorliegt. Sobald mehrere 
Protokolle auf der gleichen Ebenen vorliegen, Querbeziehungen 
zwischen Ebenen notwendig sind oder Beziehungen uber.zwei Ebenen 
hinausgehen, ist diese Technik nicht mehr anwendbar. 

Der vorliegenden Erfindung liegt deshalb die Aufgabe zugrunde, 
eine Vorrichtung der eingangs genannten Art zur Verfugung zu 
stellen, die dem Testanwender die Moglichkeit gibt , bestehende 
Emulationen von Protokoll -Schichten in einer flexiblen und einr 
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fachen Art und Wei'se zu einem Protokoll-Stack zusammenzusetzen. 
Der Testanwender soil hierbei mit moglichst wenig Vorwissen 
auskommen • 

Zur Losung dieser Aufgabe wird erf indungsgemaS eine Vorrichtung 
zvim Aufbau eines Protokoll -Stacks vorgeschlagen, die mindestens 
eine Protokollschicht mit mindestens einer standardisierten 
Schnittstelle umfaSt sowie eine Instanz zur Verwaltung eines 
Protokoll -Stacks, der eine derartige Protokollschicht enthalt. 

Der Erfindung liegt die Idee zugrimde, eine standardisierte, 
d.h. eine generische Emulationsxomgebung zur Verfugung zu stel- 
len, die es einem Testanwender erlaubt, Protokollschicht -Emula- 
tionen je nach Bedarf in einen Protokoll-Stack einzufiigen und 
/oder mit anderen Protokollschicht -Emulationen, Skript-Inter- 
pretern oder Bedienkomponenten zu verbinden. Dadurch daB Proto- 
kollschichten mit standardisierten Schnittstellen ausgestattet 
werden, wird die Moglichkeit geschaffen, Protokollschichten in 
einfacher Weise untereinander zu verbinden bzw. Protokollschich- 
ten mit Skript-Interpretern oder Bedienkomponenten zu verbinden, 
Durch die Standardisierung der Schnittstellen wird uberdies er- 
moglicht, daS der Testanwender nur wenig Vorwissen benotigt, um 
einen Protokoll-Stack zusammenzusetzen. 

Jeder Protokollschicht und/oder jedem Skript- Interpreter wird 
hierbei eine Beschreibungsdatei zugeordnet, in der mindestens 
eine Eigenschaft der Protokollschicht und/oder des Skript -Inter- 
preters beschrieben ist • Beim Zusammenstellen eines Protokoll - 
stacks werden die Beschreibungsdateien automatisch miteinander 
verbunden. Dies kann durch die genannte Instanz zur Verwaltung 
des Protokoll -Stacks geschehen oder durch eine separate Vorrich- 
tung. Die Instanz bzw, die separate Vorrichtung stellt hierbei 
einen generischen Kommunikations- und Verwaltungsmechanismus fur 
die Protokollemulationen zur Verfugung. 

Bevorzugt umfaSt die Instanz mindestens einen lokalen Emula- 
tionsmanager , der mindestens einer Protokollschicht zugeordnet 
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ist, und einen globalen Emulationsmanager , der mit jedem lokalen 
Emulationsmanager in Verbindung steht . 

Jede Protokollschicht weist bevorzugt mindestens einen sogenann- 
ten Service-Access-Point auf, wobei jeder Service-Access-Point 
einen Eingang und/oder einen Ausgang zu einem anderen Service- 
Access-Point bereitstellt . Unter Service-Access-Point sind hier- 
bei die logischen Zugange zu einer Protokollschicht zu verste- 
hen, in die Daten fliefien (empf angend) oder an der Daten von der 
Protokollschicht zur Verfugung gestellt werden (sendend) . Auf 
die Protokollemulation angewendet, werden die Ein- und Ausgange 
der Emulationen dement sprechend SAPs genannt. In Abhangigkeit 
von der Funktion dieser Ein- und Ausgange werden verschiedene 
Arten von Inf ormationen erwartet. Erf indungsgemafi werden zwei 
Protokollschichtemulationen durch das Verbinden der geeigneten 
SAPs dieser Emulationen raiteinander verbunden. Dabei sollte 
immer ein sendender SAP der einen Emulation mit einem empfangen- 
den SAP der anderen Emulation verbunden werden. Beide SAPs soli- 
ten die gleiche Art von Daten handhaben. 

Bevorzugt weist jede Protokollschicht weiterhin einen Eingang 
und einen Ausgang zur Verbindung mit der Instanz auf, insbeson- 
dere zur Verbindung mit einem lokalen Emulationsmanager. 

Erf indungsgemaS ist es moglich, eine Protokollschicht- derart zu 
konf igurieren, daS sie mit mindestens zwei hoheren Protokoll- 
schichten und/oder mindestens zwei niedrigeren Protokollschich- 
ten verbindbar ist. 

Die- in den Beschreibungsdateien abgelegten Eigenschaf ten umf as- 
sen beispielsweise eine Beschreibung des mindestens einen Servi- 
ce-Access-Points, insbesondere durch eine Auflistung von Primi- 
tiven, die uber den jeweiligen Service-Access-Point ausgetauscht 
werden konnen, einstellbare und/oder konstante Parameter der 
Protokollschicht sowie Aktionen der Protokollschicht. 
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Um den Testanwendern zu ermoglichen, daS sie mit geringstmog- 
lichem Vorwissen auskonunen, ist in einer besonders bevorzugten 
Weiterbildung der Erfindung vorgesehen, daS die Primitiven. jeder 
Protokollschicht \lber standardisierte Strukturen und standardi- 
sierte Kodierung abbildbar sind. 

Vorteilhaft ist es, wenn die Service-Access-Points durch Verwen- 
diing von Kommxmikationsfunktionen der Instanz nachgebildet ist. 

In einer bevorzugten Ausfuhrungsf orm ist vorgesehen, daS sie 
weiterhin ein Interaktionselement , beispielsweise einen Skript- 
Interpeter umfaSt, uber das ein Benutzer mit mindestens einer 
Protokollschicht interagieren kann. Die Vorrichtung kann weiter- 
hin uber eine graphische Benutzeroberf lache verfugen, uber die 
der Benutzer den Protokoll- Stack zusammensetzen kann. Die gra- 
phische Benutzeroberf lache stellt bevorzugt protokollschicht- 
spezifische Information bereit, wobei insbesondere einstellbare 
xind/oder konstante Parameter der Protokollschicht und/oder Ak- 
tionen der Protokollschicht durch den Benutzer modif izierbar 
sind. Die vom Benutzer vorgenommenen Modif ikationen werden in 
den Beschreibungsdateien berucksichtigt . 

Nach Beendigung der Eingabe des Benutzers werden von der Instanz 
bzw. der zusatzlichen Vorrichtvmg die aktuellen Beschreibungs- 
dateien wunschgemaS zu einem Protokoll -Stack zusammengefugt , 
ohne daS ein weiteres Aktivwerden des Benutzers notig ware. 

GemaS einem weiteren Aspekt der Erfindung wird ein Verfahren zum 
Aufbau eines Protokoll -Stacks zur Verfugung gestellt, bei dem in 
einem ersten Schritt eine Protokollschicht mit mindestens einer 
standardisierten Schnittstelle bereitgestellt wird. In einem 
zweiten Schritt wird ein Protokoll-Stack, der mindestens eine 
derartige Protokollschicht enthalt, wahlfrei zusammengesetzt . In 
einem dritten Schritt wird eine Instanz zur Verwaltung des der- 
art zusammengestellten Protokoll-Stacks bereitgestellt . 
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Die Erfindung \imfaSt weiterhin einen Protokolltester , der eine 
erfindungsgemaSe Vorrichtxang zum Aufbau eines Protokollstacks 
lunfaEt. Weitere vorteilhafte Weiterbildungen der Erfindung sind 
in den Unteranspruchen definiert. 

Im Folgenden wird nunmehr ein Ausfuhrungsbeispiel unter Hinweis 
auf die beigefugten Zeichnungen naher beschrieben. Es stellen 
dar : 

Fig. 1 in Blockschaltbilddarstellung das Zusammenwirken be- 
stimmter Bauteile eines erf indungsgemaSen Protokoll- 
testers; 

Fig. 2 in Blockschaltbilddarstellung ein Interface-Board des 

Protokolltesters gemSS Fig. 1; 
Fig. 3 in schematischer Darstellxxng einen Emulationsmanage- 

ment - Layer ; 

Fig. 4 in schematischer Darstellung die moglichen Aus- und 

Eingange einer Emulation; 
Fig.. 5 eine erste Benutzeroberf lache des Protokollstack-Edi- 

tors ; 

Fig. 6 eine zweite Benutzeroberf lache des Protokollstack- 
Editors ; 

Fig. 7 in Blockschaltbilddarstellung eines mit der Erfindung 

realisierbaren Protokollstacks; 
Fig. 8 in detaillierterer Darstellung die Interaktionen des 

Protokollstacks von Fig. 7. 

Fig. 1 zeigt in Blockschaltbildf orm Bestandteile eines erfin- 
diingsgemafien Protokolltesters, namlich ein PC-Board 10, bei- 
spielsweise ein Intel Pentium 133 CPU mit Windows NT 4.0 Be- 
triebssystem, 64 MB RAM sowie 4 GB Harddisk, mit einer graphi- 
schen Benutzerschnittstelle (GUI;- graphical user interface) 12, 
ein Application Board 14, beispielsweise eine Applikationspro- ' 
zessorkarte mit einem Motorola 68040 CPU mit vxWorks Echtzeit- 
betriebssystem sowie 32 MB RAM. Die Application Board 14 enthalt 
einen globalen Emulationsmanager 16, Analyzer Bubbles 18 sowie 
einen lokalen und eine globalen Pipeline-Manager .20, 22... Der 
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Protokolltester enthalt weiterhin mehrere, bevorzugt sechs In- 
terface-Boards 24a, 24rx, beispielsweise fur El/Tl, S0/U2B1Q/V/X 
und ATM- Inter f aces tandards . Die Realisierung kann erfolgen bei- 
pielsweise durch eine Motorola 68040 oder eine Intel 960 CPU mit 
vxWorks Echtzeitbetriebssystem. Auf jedem Interface -Board bef in- 
det sich ein lokaler Emulationsmanager 2 6a, 26n, ein Remote 
Transfer Layer 28a, 28n sowie. ein Treiber 30a, 30n. Alle Boards 
konunixnizieren uber einen VME-Bus. Ein Emu lationsmanagement- Layer 
wird gebildet aus den lokalen Emulationsmanagern sowie einem 
globalen Emulationsmanager. Der Emulationmanagement -Layer dient 
zur Steuerung der Zusammenarbeit , der Installation sowie der 
Konf iguration eines Protokoll -Stacks . Um ein einf aches Zusam- 
mensetzen eines Protokoll -Stacks zu ermoglichen und vom Be- 
triebssystem unabhangig zu sein, sind die Interface-Boards 24a 
bis 24n einheitlich, d.h. standardisiert' aufgebaut. 

Fig. 2 zeigt ein Interface -Board 24, woraus hervorgeht, daS ein 
lokaler Emulationsmanager 26 einen Emulations -Interface -Layer 32 
enthalt, der eine Abstraktionsschicht darstellt zwischen dem 
Betriebssystem und jeder Emulation 34a, 34b, 34c. Er stellt eine 
Schnittstelle fur logische Kommunikationswege zu den Emulationen 
bereit und verwendet externe Queues, um sie zu implementieren. 
Der Emulations-Interf ace-Layer 32 stellt den Emulationen Funk- 
tionen bereit, um Speicher zuzuweisen, Buffer zuzuteilen. Timer 
zu starten und zu stoppen und Ablaufverf olgungsnachrichten zu 
senden. Lediglich fur die Installation und die Deinstallation 
der Emulationen importiert der Emulations-Interf ace-Layer 32 
Funktionen, um die Emulationen zu initialisieren, zu deinitiali- 
sieren und eine Funktion zum Start der Emulation. 

Administrative Abfragen zum globalen Emulations -Manager 16 kon- 
nen dem Zweck dienen, eine Emulation innerhalb einer spezif i- 
zierten Protokoll-Stacks, d.h. auf Emulationsebene betrachtet 
innerhalb einer sogenannten Emulationspipeline zu erzeugen oder 
zu loschen. Parameter einer Emulation zu konf igurieren oder 
abzufragen, ein Menusystem' fur Emulationsparameter abzufragen 
und Kommunikationspf ade zwischen Emulationen zu verbinden. Jede 



administrative Abfrage an den lokalen Emulationsmanagement- Layer 
wird durch einen Fxmktionsauf ruf imd einen ASCII-String, ■ der 
leicht lesbar ist, durchgef uhrt . Administrative Abfragen von der 
Benutzerseite an lokale Emulationsmanagement-Layer werden soweit 
m6glich ohne Unterbrechung der Emulation gehandhabt. Generell 
kann hierbei eine Emulation eine oder mehrere Protokollschichten 
umfassen. 

Fig. 3 zeigt schematisch einen Emulationsmanagement-Layer 36, 
der uber einen Eingang 38 mit den Emulations-Interf ace-Layern 
der einzelnen Emulationen in Verbindung steht sowie uber einen 
Eingang 40 mit dem globalen Emulations -Manager 16 fur die Ctoer- 
nahme von Funktionen, der Installation und der Konf iguration des 
Protokoll -Stacks sowie fur Ereignisse, die von auSen beispiels- 
weise vom Benutzer kommen. Uber einen Ausgang 42 kann der Emula- 
tionsmanagement-Layer 36 eine Emulation initialisieren, deini- 
tialisieren und starten. 

Fig. 4. zeigt eine Emulation 34, die - wie erwahnt - eine oder 
mehrere ■ Protokollschichten umfassen kann. Uber standardisierte 
SAPS sind Verbindungen moglich zu einer darOberliegenden 
Schnittstelle, siehe Pfeil 44, zu einer darunterliegenden 
Schnittstelle, siehe Pfeil 46, sowie zur Emulationsmanagement- 
Schicht, siehe Pfeil 48. Unter Schnittstelle sind weitere Proto- 
kollschichten, Emulationen, Skript- Interpreter zu verstehen. 

Die SAPS der einzelnen Schnittstellen konnen durch den Benutzer 
in beliebiger Weise miteinander verbunden werden. Zur Realisie- 
rung der Verbindung, siehe unten. verwaltungskommandos an. die 
Verwaltungsinstanz, d.h. den aus dem globalen und den lokalen 
Emulationsmanagern gebildeten Emulationsmanagement-Layer werden 
durch lesbare ASCI I -Text -Strings formuliert. Die folgenden 
Schlusselworter wurden fur den Request (Anf orderungs- ) String 
def iniert: 
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create (emulname) [, (createname) [, (searchpath)] ] 

Dieses Schlusselwort wird verwendet, um anzufordern, daS die 
Interf aceschicht eine Emulation, die als (emulname) bekannt 
ist, ladt. Wenn der Parameter (createname) gegeben ist, er- 
halt die Emulation diesen Namen innerhalb der Emulationspipe- 
line. Andernfalls erhalt die Emulation den Namen (emulname) 
innerhalb der Pipeline. Keine Emulation darf einen Namen mit 
einer Zahl als erstes Zeichen haben, well dies eine Identifi- 
kation fur eine Ausgangs- oder Eingangsverbindung zu einer 
physikalischen Schnittstelle ist. Wenn der Parameter 
(searchpath) gegeben ist, wird das Objektmodul innerhalb des 
Verzeichnisses des gegebenen Suchpfads gesucht werden. 

unload (emulname) 

Ixinerhalb der Emulationspipeline wird eine Emulation gesucht 
werden, die in der Pipeline den Namen (emulname) tragt . Wenn 
die Emulation gefunden ist, wird sie aus der Pipeline ge- 
loscht . 

connect (emulnamel) . (outputl) , (emulname2 ) . (input 2 ) 
connect (logical link identifier ), (emulname2 ). (input2 ) 
connect (emulnamel) , (outputl) , (logical link identifier) 
connect (boardnumberl ) . (boardlinkl ) , (emulname2 ) . (input 2 ) 
connect (emulnamel ) . ( output 1 ) , (boardnumber2 ) . (boardlink2 ) 
connect (boardnumberl) . (boardlinkl) , (logical link identifier) 
connect (logical link identifier) , (boardnumber2 ) . (boardlink2 ) 

Das connect -Schlusselwort wird verwendet zur Herstellung von 

Verbindungen zwischen : 

einem Ausgang . einer Emulation mit einem Eingang einer 
anderen Emulation; 

einer logischen -Verbindung einer physikalischen Schnitt- 
stelle (durch den logischen Eingangsverbindungsidentif ika- 
tor (logical input - link identifier) als eine Nummer be- 
zeichnet) mit einem Eingang einer Emulation; 
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- einem Ausgang einer Emulation mit einer logischen Aus- 
gangsverbindung einer physikalischen Schnittstelle (durch 
einen logischen Verbindungsidentif ikator (logical link 
identifier) als eine Ntutimer bezeichnet) ; 

- eine interboardverbindung (die aus der lokalen Boardnummer 
und einer verbindungsnummer 0. . .31 dieses Boards besteht) ; 

- ein Ausgang einer Emulation zu einer Interboardverbindung 
(die aus der lokalen Boardnummer und einer Verbindungs- 
nummer 0...31 dieses Boards besteht) 

- einer interboardverbindung (die aus einer lokalen 
Boardnummer und einer Verbindungsnummer 0...31 dieses 
Boards) mit einer logischen Ausgangsverbindung eines phy- 
sikalischen interface (durch einen logischen Verbindungs- 
identif ikator (logical link identifier) als eine Nummer 
bezeichnet) ; 

- einer logischen Verbindxing eines physikalischen Interface 
(durch einen logischen .Inputverbindungsidentif ikator (lo- ' 
gical input link identifier) als eine Nummer bezeichnet) 
an eine Interboardverbindung (die aus der lokalen Board- 
nximmer und einer Verbindungsnummer 0...31 dieses Boards 
besteht) . 

VereinbarungsgemaS ist zu beachten, daS keine Emulation einen 
Namen mit einer Ziffer als erstes Zeichen haben darf, weil 
dies eine Identif ikation fur einen Ausgang oder Eingang zu 
einer physikalischen Schnittstelle ist. 

disconnect (emulname> . (output > 

disconnect (logical link identifier) 

disconnect (boardnumber) . (boardlink) 

Das schlusselwort zur Verbindungslosung wird verwendet, urn 
eine bestehende Verbindung zu losen, die ausgeht von 

- einer Emulation (z.B. zu einer anderen Emulation); 

- einer logischen Verbindung, die durch einen logischen 
verbindungsidentif ikator als eine Nummer bezeichnet ist; 

. - eine interboardverbindung durch die Boardnummer und die 
Interboardverbindung. 



. 1 : : . : .. ': :^. ' — y- '-r-^' -vy , 
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Vereinbarungsgemafi muS nur der Verbindungsursprung angegeben 
warden . 

config (emulname) . {parametername) = (value) 

Dieses Schlusselwort wird verwendet, um einen Parameter einer 
Emulation zu Jconf igurieren. Der Name der Emulation ist durch 
(emulname) gegeben, der zu konf igurierende Parameter der 
Emulation ist mit (parametername) und der dem bezeichneten 
Parcimeter zu gebende Wert mit (value) bezeichnet . 

query ( emulname ) . ( parametername ) 

Dieses Schlusselwort wird verwendet, um von der Emulations- 
management schicht den Wert eines Parameters abzufragen der 
durch eine gegebene Emulation veirwendet wird. Der Name der 
. Emulation ist gegeben durch (emulname) , der Parametername, ist 
gegeben durch (parametername) , Die Emulationsmanagement- 
schicht sendet eine Antwortnachricht die aus einem lesbaren 
ASCII-String besteht an die abfragende Applikation, 

list 

Das Schlusselwort list wird verwendet zur Anfrage bei der 
Emulationsmanagementschicht eine Liste von Emulationspipe- 
lines zuruckzusenden . Die Emulationsmanagementschicht sendet 
die Antwortnachricht, die aus einem lesbaren ASCII -String 
besteht, an die abfragende Applikation. 

show [ ( emulname ) ] 

Dieser Befehl wird verwendet, um Inf ormationen betreffend 
eine Emulationspipeline zu erhalten. Es ist moglich, den 
Namen einer Emulation (emulname) der Pipeline anzugeben, dann 
wird die Antwortinf ormation auf diese eine Emulation be- 
schrankt . Die Antwort auf diesen Befehl hat das f olgende 
Format : 

(outputname) -) (destination! ) 
(inputname) (- (sourcel) 
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Die Emulation, die unter Verwendung des Moduls des Namens 
(modulname> ituft, wird innerhalb der Pipeline als (emula- 
tionname) bezeichnet. 

Diese Emulation hat mehrere Ausgangsverbindungen und Ein- 
gangsverbindungen. Diese Verbindungen werden (output- 
namel>...(outputnameX> und (inputnamel) . . . <inputnameX> ge- 
nannt. Jeder Ausgang muS mit einer Zieladresse verkettet 
sein. Die Zieladresse wird angegeben mit (destinationl) 
. (destinationX) . Jede Eingangsverbindung muS mit einer 
Sourceline verkettet sein. Diese Sourcelines werden 
{ sourcel > . . . ( source2 > genannt . 

Die Definition einer Zieladresse kann eines der folgenden 
Syntaxf ormate haben: 

(destinationemulation) . (destinationinput) 
LDD (= Logical Data Destination) 
. AP (= Applikation. die angebunden werden kann) 
wenn die Zieladresse (destination) der Ausgangsverbindung 
eine Emulation ist, dann wird der Name der entfernten Emula- 
tion ' (destinationemulation) und der Name des entfernten Ein- 
gangs (destinationinput) angegeben. Wenn die Ausgangsverbin- 
dung direkt an die Applikation oder die logische Datenziel- 
adresse (logical data destination) gekoppelt ist, ist dies 
durch die Worte LDD oder AP gegeben. 

Die Definition einer Quelle kann eines der folgenden Syntax- 
formate besitzen: 
( sourceemulation) . ( sourceoutput ) 
LDS (= Logical Data Source) 
AP 

wenn die Quelle zur Eingangsverbindung eine Emulation ist, 
dann werden der Name der entfernten Emulation (sourceemula- 
tion) und der Name des- entfernten Ausgangs (sourceoutput) 
angegeben. Wenn die Eingangsverbindung direkt an die Applika- 
tion Oder die logische Datenquelle (logical data source) 
gekoppelt ist, ist dies durch die. Worte AP oder LDS angege- 
ben. 



menu ( emulname ) 

Dieser Befehl wird verwendet, tun Inf ormationen bezuglich der 
Konf iguration xmd Abf ragefunktionalitat der Emulation mit dem 
Namen (emulname) zu erhalten. Die gegebene Information kann 
verwendet werden, um dem Anwender einen komfortablen Menuauf- 
bau zu zeigen. Die Antworten auf diesen Befehl dienen der 
Definition von Variablen und Untermenus. Variablen- und Un- 
termenuangaben sind in Zeilen aufgeteilt. Die Antworten auf 
diesen Befehl haben die folgenden Schlusselworte: 

(name) : 

type = int (min) . . . (max) ; 
access = (access); 
default = (default); 

Die Variable ist vom Integer-Typ. Der Name der Variablen ist 
gegeben * durch (name). Der Integer-Wert der Variablen muS im 
Bereich (min) bis (max) liegen. 

(name) 

type = enum (valuel)/(value2)/ . . . ; 
access = (access); 
default = (default); 

Die Variable ist vom Auswahltyp . Der Name der Variablen ist 
durch (name) gegeben. Die moglichen Werte der Variablen sind mit 
der Liste von (valuel), (value2) usw. gegeben. 

(name) : 

type=:string ( length ) ; 
access =(access); 
default = (default); 

Die Variable ist ein String von ASCII -Zeichen. Der Name der 
Variablen ist gegeben durch (name).. Die Lange des Strings ist 
gegeben durch (length). . 

(name) : 

type=numbers( length); 
access= ( access ) 
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default= (default ) 

Die Variable ist ein String von Zahlen ( ' 0 ' . . . ' 9 ' ) . Der Name der 
variablen ist gegeben durch (name). Die Lange des Strings ist 
gegeben durch. (length) . 

(name) 

type=hexnumber s ( length ) 
access= ( access ) 
default= (default ) 

Die Variable ist ein String von Hexadezimalnummern ( ' 0 ' . . . ' 9 ' , 
'a'..'f' ) Zeichen. Der Name der Variablen ist gegeben durch 
(name). Die Lange des Strings ist gegeben durch (length). 

(name) 

type=telnumbers (length) 
access= (access) 
def ault= (default ) 

Die Variable ist ein String von Telef onnummernzeichen 
('0'...'9', 'a'..'f', '#'). Der Name der Variablen ist gegeben 
durch (name). Die Lange des Strings ist gegeben durch (length). 

(name) 

type=bit string ( length ) 
access= (access) 
def ault= (def ault ) 

Die Variable ist eine Anzahl von Bits . Jedes Bit ist modif iziert 
durch ein Digit ('0' oder '1') eines gegebenen Strings. Die 
Lange des Strings ist gegeben durch (length) . 

Jede variable ist mit einer Zugangsklasse (access) des Typs ' rd' 
(nur lesen) , 'wr' (nur schreiben) Oder ' rdwr' (lesen und schrei- 
ben) verknupft, die als ein Parameter nach der Angabe des Va- 
riablentyps angegeben wird. Jede. Variable kann als ein Feld an- 
geordnet seinl In diesem Fall wird der Name der Variablen um 
eine Indexangabe erweitert . Jede Indexangabe ist in Klammern 
eingefugt ' ['and'] ' . Der Typ einer Indexspezif ikation kann eine 
normales Ganzzahl oder eine Auf zahlnximmer sein. Definition: 
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(namestring) [int (min) . . . (max) ] : 

In diesem Fall ist der Index zur Variablen mit dem Namen 
(namestring) vom Integer-Typ. Der Umfang der Variablen ist 
durch (min) . , , (max) gegeben. 

(namestring) [eniim(valuel*)/ (value2 ) / * . .] : 

In diesem Fall ist der Index zur Variablen mit dem Namen 
(namestring) vom Auf zahlungsniimmerntyp . Die moglichen Werte 
■ des Index sind als eine Liste von (valuel ) . . . (value2 ) usw. 
gegeben . 

Es ist mogich eine Struktur von Untermenus in dem Menu unter- 
zubringen. Die Syntax fur eine Untermenuangabe ist vom folgenden 
Format : 
( name ) : { 

[ ( variabledeclarations ) ] 

[ (menudeclarations ) ] 

} 

Der Name des Untermenus ist durch (name) . gegeben. Die Varia- 
blen Oder weiteren Untermenus, die zu dem aktuell angegebenen 
Untermenu gehoren, sind in Klammern angefugt '{'and'}'. 

bindreq ( emulname ) . ( input ) [ , ( data ) ] 

Dieser Befehl wird verwendet , um eine Bind-Auf trags-Primitive 
(bind rec[uest) an einen Eingang einer Emulations zu lei ten. 
Die Emulation wird durch ihren Namen (emulname) gegeben und 
durch ihre Eingangsverbindung (input). Die Primitive wird mit 
Daten der optionalen Parameter (data) gefullt (in hexadezima- 
lem Format) . 

sendreq (emulname ). (input ), (primld) [/(data)] 

Dieser Befehl wird verwendet, um eine Primitive. an den Ein- 
gang einer Emulation zu leiten. Die Emulation ist durch ihren 
Namen (emulnsane) und ihre Eingangsverbindung (input). Es wird 
eine Primitive mit dem angegebenen Identif ikator (primld) er- 
zeugt und die Primitive wird mit Daten des optionalen Para- 
meters (data) (in hexadezimalem Format) gefullt.. 
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exec ( f ilename ) 

Dieser Befehl wird verwendet, um den Emulationsmanagement- 
Layer mit dem Lesen des Befehls-Strings fur die obere 
Schnittstelle von der Datei mit dem Namen (filename) zu be- 
au ft ragen. 

board (boardnumber) : (request) 

Dieser Befehl wird verwendet, xm einen Auftrag (request) an 
das durch (boardnxomber ) gegebene Board zu lei ten. 

Wie erwahnt, stellt die durch die lokalen und den globalen Emu- 
lations-Manager gebildete Verwaltungsinstanz , oben auch als 
Emulationsmanagement-Layer bezeichnet, einen generischen Kom- 
munikations- und Verwaltungsmechanismus fur die Emulationen zur 
Verfugung. Sinn dieser Verwaltungsinstanz ist es, die Protokoll- 
emulationen, die Skript interpreter und die Bedienkomponenten, 
die fur den Protokoll- Stack bzw. fur den gewunschten Teil des 
Protokoll- Stacks benotigt werden, in ein abstraktes Gebilde, die 
Emulations-Pipeline zu laden und zu verbinden. Dieses. Laden und 
Verbinden kann der Anwender des Protokolltestsystems selbststan- 
dig und ohne tiefergehendes Verstandnis der Struktur des Proto- 
kolltestsystems am Protokolltester steuern. Far diese Steuerung 
kann eine graphische Benutzeroberf lache oder eine Textdatei 
verwendet werden. 

Die den jeweiligen Protokollschichten bzw. Protokollemulationen 
zugeordneten Beschreibungsdateien erraoglichen es der graphischen 
Benutzeroberf lache, Inf ormationen uber die Protokollemulationen 
darzustellen. Diese Inf ormationen bestehen im wesentlichen aus : 

- einer allgemeinen Beschreibung uber die Protokollemulation, 
den Skript interpreter oder die Bedienkomponente • selbst ; 

- den Namen aller vorhandenen Service-Access-Points ffir die 
Eingangs- und die Ausgangsrichtung ; 

- eine Beschreibung jedes einzelnen Service-Access-Points; 

- einer Auflistung der Primitiven, die uber jeden einzelnen 
Service-Access -Point ausgetauscht werden konnen; 
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- einer Beschreibung aller Primitiven; 

einer Auflistung der Parameter fur jedes einzelne Primitive; 
einer Beschreibung aller Parameter, die in Primitiven ver- 
wendet we r den; 

einer Beschreibung der Variablen, Konstanten und Aktionen, 
die innerhalb der Protokpllemulation gesetzt, abgefragt oder 
gestartet werden Iconnen, wobei diese Beschreibung auch die 
Gruppierung in Menues, Untermenues und Felder ermoglicht; 
sowie zusatzliche Angaben fur Statistikfunktionen. 

Das generische Konzept der Verwaltungsinstanz vmd die Informa- 
tionen aus den Beschreibungsdateien ermoglichen es dem Anwender 
auf komfortable Weise am Testsystem Module zu den gewunschten 
Applikationen zusammenzustellen, Diese Flexibilitat erhoht fur 
viele Anwendungen den Nutzwert des Protokolltestsystems , spart 
erheblichen Entwicklungsauf wand sowie Verzogerungen im Test fort - 
schritt . 

Die in den Beschreibungsdateien zur Verfugung gestellten Infor- 
mationen konnen auch von anderen Werkzeugen im Protokolltest 
verwendet werden, um den Benutzer besser zu fuhren und ihn bei 
der Erstellung von Testfallen mit protokollspezif ischem Wissen 
zu unterstutzen- 

Die Beschreibungsdatei, die fur jede Protokollemulation, jeden 
Skript- Interpreter und jedes Bedienelement vorliegen muS, ist im 
Text format gehalten, Im Folgenden ein Auszug aus einer solchen 
Datei, deren Inhalt sich einem Fachmann auf dem Gebiet der vor- 
liegenden Erfindung ohne weiteres erschlieSt: 

[GENERAL] 
Name=ss7isupl 

Description="ISDN User Part"; 
Type = Emul a t i on ; 
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[STATISTIC] 

Statistic Module: type=enxim ON/OFF; access=rdwr ; def ault=OFF; 
Statistic interval: type=int 1..3600; access=rdwr; default=10; 

[MENU] 
General : { 

version: type=string 80; access=rd; coininent= " " ; statistic=N/A; 

default="SS7. ISUP VI. 00"; 
State : type=enuin NOT_LOADED/ IDLE/ACTIVE/WARNING/ERR0R/N0_ANSWER ; 

access=rd; conunent="" ; statistic=N/A; def ault=NOT_LOADED; 
State Description: type=string 256; access=rd; conunent=" " ; 

statist ic=N/A; def ault=emulation not loaded; 
Standard: tYpe=enuin White Book ISUP; access=rdwr; coinment=""; 

statistic=N/A; def auit=White Book ISUP; 

} 

Networks : { . 
Network natO: { 

use: type=enum no/yes; access=rdw; coininent=" " ; stati- 
st ic=N/A; default=no; 
NI: type=enuin nato/natl/into/intl ; access=rd; com- 

nient=""; statistic=N/A; def ault=natO ; 
OPC: type=int 0.. 16383; access=rdwr; coniment= " " ; stati- 
stic=N/A; default=0; 
}. 

[SAPS] 

Network natO: .mode=in; location=lower ; comment=""; asps = 

UDAT_IND; 

Network intl: mode=in; location=lower ; coiTunent=" " ; 
' Call Terminal: inode=in; location=upper ; coinment=""; asps = 

DATA_REQ; 

Maintenance Terminal: mode=in; location=upper; comment=»"; 

aspS=RESET_REQ , RESET_RES , 

CONTRECHECK_REQ, STOP_REQ, 
BLOCKING_REQ , BLOCKING_RES , 
UNBLOCKING_REQ , 
, UNBLOCKING_RES ; 
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Network natO: mode=out; location= lower; comment^" " ; 

asps =UDAT_REQ ; 
Network int 1 : inode=out ; location=lower ; comment = " " ; 

a sp s =UDAT_REQ ; 
Call Terminal : mode=out ; location=upper ; comment = " " ; 

asps=DATA_IND ; 

Maintenance Terminal ; mode=out ; location=upper ; comment= " " ; 

asps=RESET_IND , 
RESET_CNF; 
CONTRECHECK_CNF , 
STOP^CNF, 
BIiOCKING_IND, 
BLOCKING_CNF, 
UNBLOCKING_IND , 
UNBLOCKING_CNF , 
STARTRESET_IND , 
CALriFAILURE_IND , 
MAINTENANCE_IND ; 

' tASPs] . 

RESET_REQ: id=0x0001; comment=""; 

Paral=NI; para2=DPC; para3=CIC; 
RESET_RES : id=0x0 002 ; comment-" " ; 

Paral=NI; para2=DPC; para3=CIC; 
CONTRECHECK_REQ : id= 0x0 003; coinment = " " ; 

Paral=NI; para2=DPC; para3=CIC; 

[PRMs] 

NX : comment=""; size=2 ; values=nat0=2/natl=3/int0 = 0/intl=l; 

def ault=2 ; 
DPC : comment^""; size=2; 
OPC : comment^""; size=2; 
CIC : comment^""; size=2; 

Im Rahmen der graphischen Benutzeroberf lache des Ausfuhrungsbei- 
spiels wird ein Editor bereitgestellt , der einen Benutzer beim 
Zusammenstellen eines Protokoll- Stacks iinterstutzt . Fig. 5 zeigt 
eine erste Bedienoberf lache des Editors, die sogenannte Diagram- 
View-Oberf lache als Beispiel einer generisch- arbeitenden graphi- 
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schen Benutzeroberf lache. Rechts auf der graphischen Benutzer- 
oberfiache sind vom Benutzer Bedienfxinktionen anwahlbar, mit 
denen eine Protokoll-Stack, aufgebaut werden kann. Links auf der 
graphischen Benutzeroberf lache ist ein Protokoll-Stack zu erken- 
nen, wobei der Schicht ss7isupl in paralleler Weise, zwei 
Schichten ubergeordnet sind, namlich die Schichten ssVisupterml 
und ss 7 i supmaint 1 . 

Fig. 6 zeigt eine zweite Benutzeroberf lache des Protokollstack- 
Editors, namlich die Parameter-View-Benutzeroberf lache . Hier 
konnen Variablen, Konstanten und Aktionen von Protokoll (schicht - 
)emulationen bearbeitet werden. Im linken Teilfenster ist zu- 
nachst erkennbar, daS man sich im Verzeichnis Stack befindet, 
dem verschiedene Protokoll schicht en, beispielsweise ss7mtp2a, 
ss7mtp3a, ss7isupl usw. untergeordnet sind. Innerhalb der je- 
weiligen Schicht sind verschiedene Directories anwahlbar, bei- 
spielsweise General fur Allgemeines, Timers fur Zeitmarken sowie 
Actions fur Aktionen. Bei der Schicht ss7mtp3a sind im Unter- 
verzeichnis Layer 4 die einzelnen SAPs erkennbar. Unter der 
Schicht SS7isupmaintl ist erkennbar, daS Primitiven angewahlt 
werden konnen. Die rechten beiden Teilfenster zeigen informatio- 
nen zvim SAP (0) des Layers 4 der Protokollschicht ss7mtp3a. 

Fig. 7 zeigt beispielhaft eine andere Darstellung eines mit der 
Erfindung realisierbaren Protokoll - Stacks . Von oben nach unten 
sind folgende Schichten aneinandergereiht : 

- TCP/IP 50; 

SNDCP (subnet dependent convergence protocol) 52; 

- LLC (logical link layer) 54; 

- Parallel zum SNDCP 52 und LLC 54: GMM/SM (GPRS mobility mana- 
gement and session control) 56; 

- BSSGP (bay station system GPRS protocol) 58; 
NS (network service) 60; 

- FR (frame relay) 62. 

Der gezeigte Protokoll-Stack ist dem Gb-Interface von GPRS ent- 
nommen. Die Protokollschichten FR, NS, BSSGP und LLC sind auf 
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dem realisierten Protokolltester innerhalb einer einzigen Emula- 
tion mit der Bezeichnung LLC/BSSGP/NS/FR zusammengef aSt . Die 
Protokollschicht GMM/SM ist durch ein FORTH-Skript zu simulie- 
ren. Die TCP/lP-Pakete sind innerhalb eines. Ladegenerators ge- 
speichert, der in der Lage ist, Pakete kontinuierlich zu ver- 
senden . 



Fig.. 8 zeigt in detaillierterer Form die Interaktionen der ein- 
zelnen Protokollschichten des in Fig. 7 dargestellten Protokoll- 
Stacks . 



Zur Erzeugung des Protokoll-Stacks der Figuren 7 und 8 sind 
lediglich die folgenden Verwaltungskommandos an die Verwaltungs- 
instanz zu geben: 

create LLCl 

create SNDCP 

create LOAD 

creat FORTH1197 , FORTH 

connect LOAD . Load , SNDCP . SNDCPuser 
connect SNDCP .SNDCPuser, LOAD. Load 

connect LOAD. Ctrl, FORTH. In2 
connect FORTH. Out2 , LOAD. Ctrl . 

connect SNDCP. LLC, LLCl. LLuserO 
connect LLCl .LLuserO, SNDCP. LLC 

connect SNDCP , SNSM, FORTH . Inl 
connect FORTH. Outl, SNDCP. SNSM 

connect LLCl . MMuserO , FORTH . InO 
connect FORTH .Out 0 , LLCl .MMuserO 



connect LLCl . Lower , 1 
connect 0 , LLCl . Lower 
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Vorrichtung zum Aufbau eines Protokoll-Stacks 
und zugehoriges Verfahren 



ANSPRUCHE: 



Vorrichtung zum Aufbau eines Protokoll-Stacks umfassend: 

a) mindestens eine Protokollschicht mit mindestens einer 
standardisierten Schnittstelle (44, 46) ; 

b) eine Instanz (16,26) zur Verwaltung eines Protokoll- 
Stacks, der die Protokollschicht aus a) enthalt. 

Vorrichtung nach Anspruch 1, 
dadurch gekennzeichnet , 

daS jeder Protokollschicht und/oder jedem Skript- Interpre- 
ter eine Beschreibungsdatei zugeordnet ist, in der minde- 
stens eine Eigenschaft der Protokollschicht und/oder des 
Skript-Interpreters beschrieben ist . 

Vorrichtiing nach Anspruch 2 , 
dadurch gekennzeichnet , 

daS sie Mittel (36) aufweist, mit denen die Beschreibujigs- 
dateien der Bestandteile eines Protokoll-Stacks miteinander 
verbindbar sind, 

Vorrichtung nach einem der vorhergehenden Anspruche, 

dadurch gekennzeichnet , 

daS die Instanz vimfaSt 

mindestens einen lokalen Emulationsmanager (26) , der 
mindestens einer Pr.otokollschicht zugeordnet ist, und 
einen globalen Emulationsmanager (16) , der mit jedem 
lokalen Emulationsmanager in Verbindvmg steht . . 



Vorrichtung nach einem der vorhergehenden Anspruche , da- 

durch gekennzeichnet , 
daS jede Protokollschicht mindestens einen Service Access 
Point aufweist, wobei jeder Service Access Point einen Ein- 
gang iind/oder einen Ausgang zu einem anderen Service Access 
Point auf weist . 

Vorrichtung nach einem der vorhergehenden Anspruche, 
dadijjrch gekennzeichnet, 

dafi jede Protokollschicht einen Eingang und einen Ausgang 
zur Verbindung mit der Instanz (16,26), insbesondere 
mit einem lokalen Emulationsmanager auf weist. 

7. Vorrichtung nach einem der vorhergehenden Anspruche, 
dadurch gekennzeichnet, 

daS eine Protokollschicht derart konf igurierbar ist, daS 
sie mit mindestens zwei hoheren Protokollschichten und/oder 
mindestens zwei niedrigeren Protokollschichten verbindbar 
ist . 

8 . Vorrichtung nach Anspruch 7 , 
dadurch gekennzeichnet, 

daS die Eigenschaf ten umfassen: 

Beschreibung des mindestens einen Service Access 
Points, insbesondere durch eine Auflistung von Primi- 
tiven, die uber den jeweiligen Service Access Point 
ausgetauscht werden konnen, und/oder 

einstellbare und/oder konstante Parameter der Proto- 
kollschicht und/oder 
Aktionen der Protokollschicht. 



9 . Vorrichtung nach. Anspruch 8 , 
dadurch gekennzeichnet, 

daS die Primitiven jeder Protokollschicht iiber standardi- 
sierte Strukturen und standardisierte Kodierung abbildbar 
sind. 



10. Vorrichtung nach einem der Anspruche 3 bis 9, 
dadurch gekennzeichnet , 

daS ein/jeder Service Access Point durch Verwendung von 
Konmunikationsfunktionen der Instanz (16 , 26) nachgebildet 
ist . 

11. Vorrichtung nach einem der vorhergehenden Anspruche, 
dadurch gekennzeichnet, 

daS sie weiterhin ein Interaktionselement umfaSt, uber das 
ein Benutzer mit mindestens einer Protokollschicht inter- 
agieren kann, 

12. Vorrichtung nach Anspruch 11, 
dadurch gekennzeichnet, 

daS uber. das Interaktionselement mindestens ein Skript- 
Interpreter in den Protokoll -Stack einbindbar ist, uber den 
ein Benutzer auf den Protokoll -Stack einwirken kann. 

13. Vorrichtung nach einem der vorhergehenden Anspruche, . 
dadurch . gekennzeichnet , 

daS die Vorrichtung weiterhin eine graphische Benutzerober- 
flache (12) umf aSt . 

14 . Vorrichtung nach Anspruch 13 , 
dadurch gekennzeichnet, 

daS uber die graphische Benutzeroberf lache (12) der Proto- 
koll-Stack zusammensetzbar ist. 

15. Vorrichtung nach Anspruch 13 oder 14, 
dadurch gekennzeichnet, 

daS uber die graphische Benutzeroberf lache (12) protokoll - 
schicht-spezif ische Information bereitstellbar ist. 
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16. Vorrichtung nach Anspruch 15, 
dadurch gekennzeichnet , 

daS protokollschicht-spezif ische Information in Form von 
einstellbaren und/oder konstanten Parameter der Proto- 
kollschicht und/oder 
Aktionen der Protokollschicht 

durch den Benutzer modif izierbar ist. 



17. 



Verfahren zum Aufbau eines Protokoll -Stacks folgende 
Schritte umfassend: 

a) Bereitstellen mindestens einer Protokollschicht mit 
mindestens einer standardisierten Schnittstelle; 

b) Wahlfreies Zusammensetzen eines Protokoll-Stacks, der 
die mindestens eine Protokollschicht aus a) enthalt; 

c) Bereitstellen einer Instanz zur Verwaltung des Proto- 
koll -Stacks - 



18 . Protokolltester mit einer Vorrichtung nach einem der An- 
spruche 1 bis 16 . 
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Vorrichtung zum Aufbau eines Protokoll-Stacks 
xxnd zugehoriges Verfahren 



ZUSAMMENFASSUNG : 

Die vorliegende Erf indung betrifft eine Vorrichttmg zum Aufbau 
eines Protokoll-Stacks mit mindestens einer Protokollschicht mit 
mindestens einer standardisierten Schnittstelle (44, 46) und 
einer Instanz (16, 26) zur Verwaltung eines Protokoll-Stacks der 
eine derartige Protokollschicht enthalt. Sie betrifft uberdies 
ein Verfahren zum Aufbau eines Protokoll-Stacks mit den Schrit- 
ten a) Bereitstellen mindestens einer Protokollschicht mit min- 
destens einer standardisierten Schnittstelle; b) wahlfreies 
Zusammensetzen eines Protokoll-Stacks, der mindestens eine der- 
artige Protokollschicht enthalt; und c) -Bereitstellen einer 
Instanz zur Verwaltung des Protokoll-Stacks. 
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